Using STR_TO_DATE() and DATE_FORMAT() in MySQL
MySQL provides two important functions for working with date strings: STR_TO_DATE() for converting strings into date values, and DATE_FORMAT() for converting date values into formatted strings.
Parses a string based on a specified format and returns a DATE, DATETIME, or TIME value.
Useful when importing data where dates are stored as strings.
Format specifiers (e.g., %d, %m, %Y) must match the input string.
This converts the string '21-11-2025' into a proper DATE value: 2025-11-21.
Formats a date value into a custom string.
Useful for displaying dates in user-friendly formats.
Requires format specifiers similar to STR_TO_DATE().
This outputs: '21/11/2025'.
STR_TO_DATE() converts a string into a date value.
DATE_FORMAT() converts a date into a formatted string.
STR_TO_DATE() is used when reading/parsing dates; DATE_FORMAT() is used when displaying dates.
Both rely on the same set of format specifiers.
In summary: Use STR_TO_DATE() to interpret a date string into a real MySQL date, and DATE_FORMAT() to output a stored date in a human-readable format.
We have a CSV import where dates appear as '31/12/2022'. Write the INSERT statement that converts that string into a DATE column using MySQL functions.
If you run SELECT DATE_FORMAT('2022-07-15', '%b %d, %Y'), what string is returned and why?
Our reporting feature expects dates in 'YYYYMMDD' format, but the source table stores them as VARCHAR in 'MM-DD-YYYY'. How would you write a SELECT that returns the dates correctly converted and formatted?
During a data migration some rows contain malformed date strings, causing STR_TO_DATE to return NULL. How would you identify those rows and provide a fallback value in a single query?
We need a daily summary table that aggregates events by date, yet event timestamps are stored as strings in several legacy formats across tables. Describe a robust conversion pipeline using STR_TO_DATE and DATE_FORMAT, addressing performance and maintainability.
Our application serves millions of users and frequently formats dates for UI. Discuss the trade‑offs of doing date formatting in MySQL with DATE_FORMAT versus handling it in the application layer.
Our organization is migrating from MySQL to a polyglot data platform. How would you refactor all existing STR_TO_DATE and DATE_FORMAT usage to ensure consistency, backward compatibility, and minimal disruption across services?
Multiple microservices store dates in different string representations due to historic reasons. Propose an architectural strategy to standardize date handling across the ecosystem, including migration plan, testing, and governance.